Hi Folks! I have the problem, that i have include-files *.inc that all are takting use of another include file (i.e. strings.inc.). i.e. refresh.dxl-includes->Tool1ImportFunctions.inc -includes-> strings.inc refresh.dxl-includes->Tool2ImportFunctions.inc -includes-> strings.inc
Because of the reuse of functions, the scripts are getting the "Unspecified Failure" and i found the solution in a post of Mathias Mamsch, who is mentioning the "sometimes"-Problem with double function declaration and same parameters: So what i am searching for: Is there a way to make it possible to include strings.inc several times in derived files without running into trouble?
Bjoern_Karpenstein - Wed Nov 11 12:15:44 EST 2015 |
Re: Unspecified failure because of #include (double function definitions) We had several discussions on includes and DXL Library architecture on the forum. If you search for it, you might get more details. My conclusion from it: - Libraries should always declare a global variable like int LIBRARY_STRING_INC = 1; on the global level. This will give you a translation error if you accidentally import the library twice. - Libraries should not include other libraries. Instead I tend to put a comment inside the libraries at the top:
//! -- Tool1ImportFunctions.inc
/*
THIS LIBRARY REQUIRES THE FOLLOWING INCLUDES:
#include <string.inc>
#include <Tool1ImportFunctions.inc>
*/
INT LIBRARY_TOOL_1_IMPORT_FUNCTIONS_INC = 0
And the same for the other library:
//! -- Tool2ImportFunctions.inc
/*
THIS LIBRARY REQUIRES THE FOLLOWING INCLUDES:
#include <string.inc>
#include <Tool2ImportFunctions.inc>
*/
INT LIBRARY_TOOL_2_IMPORT_FUNCTIONS_INC = 0
You can easily test, if the includes are sufficient, by simply copying the includes into a new Edit DXL Window and run them. Now when you make your main script and you want to include your Import Functions scripts, you need to look into both files, take the necessary includes and post them to your main: //! main program #include <string.inc> #include <Tool1ImportFunctions.inc> #include <string.inc> #include <Tool2ImportFunctions.inc> Now you simply need to remove the double includes, and you are fine. The only excuse for having a library include another one, is that the other library is never included by another file. Maybe that helps, regards, Mathias
|
Re: Unspecified failure because of #include (double function definitions) Mathias Mamsch - Thu Nov 12 02:53:47 EST 2015 We had several discussions on includes and DXL Library architecture on the forum. If you search for it, you might get more details. My conclusion from it: - Libraries should always declare a global variable like int LIBRARY_STRING_INC = 1; on the global level. This will give you a translation error if you accidentally import the library twice. - Libraries should not include other libraries. Instead I tend to put a comment inside the libraries at the top:
//! -- Tool1ImportFunctions.inc
/*
THIS LIBRARY REQUIRES THE FOLLOWING INCLUDES:
#include <string.inc>
#include <Tool1ImportFunctions.inc>
*/
INT LIBRARY_TOOL_1_IMPORT_FUNCTIONS_INC = 0
And the same for the other library:
//! -- Tool2ImportFunctions.inc
/*
THIS LIBRARY REQUIRES THE FOLLOWING INCLUDES:
#include <string.inc>
#include <Tool2ImportFunctions.inc>
*/
INT LIBRARY_TOOL_2_IMPORT_FUNCTIONS_INC = 0
You can easily test, if the includes are sufficient, by simply copying the includes into a new Edit DXL Window and run them. Now when you make your main script and you want to include your Import Functions scripts, you need to look into both files, take the necessary includes and post them to your main: //! main program #include <string.inc> #include <Tool1ImportFunctions.inc> #include <string.inc> #include <Tool2ImportFunctions.inc> Now you simply need to remove the double includes, and you are fine. The only excuse for having a library include another one, is that the other library is never included by another file. Maybe that helps, regards, Mathias
Hello Mathias, thank you very much for your reply. In such cases I am really missing object-orientated programming ;-).
With best regards, |